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(54) Asynchronous bus bridge 

(57) An asynchronous bridge (100, 120) is provided 
to allow interoperability between devices (102, 104) op- 
erating at different clock frequencies. A first command 
message from the first device (1 02, 1 04) is received and 
stored in a bridge (100, 120). The first command mes- 
sage is transmitted to the second device ( 1 04, 1 02) and 



a reply message responsive to the first command mes- 
sage is received in the bridge ( 1 00, 1 20) and transmitted 
to the first device (102, 104). This asynchronous bridge 
is useful in the development of bus components and ex- 
pansion boards and provides an interface between de- 
vices operating at independent or independently con- 
trollable clock speeds. 
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Description 

The present invention relates generally to bus inter- 
face devices, and in particular, to a method and appa- 
ratus for bridging two devices operating at different clock 
frequencies. 

The PCI local bus is a high performance 32- or 
64-bit bus with multiplexed address and data lines. The 
PCI local bus was defined to establish an industry stand- 
ard for a high performance local bus architecture offer- 
ing low cost. The PCI component and add-in card inter- 
face is processor-independent, enabling an efficient 
transition to future processor generations, and may be 
used with multiple processor architectures. This proc- 
essor independence allows the PCI local bus to be op- 
timized for I/O functions, enabling concurrent operations 
of the local bus with the processor/memory subsystem, 
and accommodating multiple high performance periph- 
erals in addition to graphics such as motion video, SCSI, 
and hard disk drives. 

The movement to enhance the video and multi-me- 
dia displays of high definition TV and other three-dimen- 
sional or high bandwidth I/O will continue to increase 
local bus bandwidth requirements. The PCI interface is 
particularly useful in interconnecting highly integrated 
peripheral controller components, peripheral add-in 
boards, and processor/memory systems. The PCI inter- 
face standard also offers additional benefits to users of 
PCI-based systems. Configuration registers are speci- 
fied for PCI components and add-in cards. A system 
with embedded auto-configuration software, it offers 
true ease of use for the system user by automatically 
configuring PCI add-in cards at power-on. The PCI Lo- 
cal Bus Specification, Rev. 2.0, which is incorporated by 
reference herein, defines the PCI interface protocol, 
electrical, mechanical, and configuration specifications 
for PCI local bus components and expansion boards. 

Situations arise whereby interoperability between 
bus components or devices with independent or inde- 
pendently controllable clocks is desired. A user may de- 
sire interoperability between a host computer and a pe- 
ripheral operating at a slower or faster clock speed. Fur- 
ther, the clock speed of either the host computer, the 
peripheral, or both may be controllable or variable. For 
example, the development of bus components and ex- 
pansion boards is expedited using hardware emulators. 
These emulators allow the developer to use easily-mod- 
ified software to test the logic implemented on the ex- 
pansion boards and verify the real-time functionality of 
the proposed design. However, the functional adapta- 
bility of the hardware emulators is not achieved without 
cost. Typically, these hardware emulators must run at 
much slower clock speeds than the host device, and are 
thus incapable of interfacing with the host bus at full 
speed. This problem is especially critical when the host 
bus serves a PCI -compliant device, because of the high 
I/O speed capability of the PCI bus. 

It is an object of the present invention to provide a 



method and apparatus for bridging a first device oper- 
ating at a first clock frequency with a second device op- 
erating at a second clock frequency. 

According to one aspect of the invention there is 
5 provided a method of bridging a first device operating at 
a first clock frequency with a second device operating 
at a second clock frequency, characterized in that it 
comprises the steps of: 

10 receiving a first command message from the first 
device in a bridge coupled between the first device 
and the second device, the message comprising a 
device command; 

storing the first command message in the bridge; 
15 transmitting the first command message from the 
bridge to the second device; 
receiving a reply message responsive to the first 
command message from the second device in the 
bridge; and 

20 transmitting the reply message to the first device. 

According to another aspect of the invention there 
is provided an apparatus for bridging a first PCI-compli- 
ant device operating at a first clock frequency with a sec- 
25 ond PCl-compliant device operating at a second clock 
frequency, characterized in that it comprises a bridge 
coupled between the first PCl-compliant device and the 
second PCI compliant device, the bridge further com- 
prising: 

30 

a first bus slave interface coupled to the first PCl- 
compliant device, the first bus slave interface com- 
prising means for receiving a first command mes- 
sage, for storing the first command message, for 

35 commanding the first PCl-compliant device to re- 
transmit the command message, for receiving the 
re-transmitted command message from the first 
PCl-compliant device, for determining if the stored 
first command message matches the re-transmitted 

40 command message, for determining if a reply mes- 
sage responsive to the first command message is 
received, for transmitting the reply message to the 
first PCl-compliant device; and 
a second bus master interface coupled to the first 

45 bus slave interface and the second PCl-compliant 
device, the second bus master interface further 
comprising means for transmitting the first com- 
mand message to the second PCl-compliant de- 
vice, and means for receiving the reply message 

50 from the second PCl-compliant device and forward- 
ing the reply message to the first bus slave inter- 
face. 

Such a method and apparatus provide an asynchro- 
55 nous bridge which is useful in the development of bus 
components and expansion boards, and which allows 
interoperability between bus components or devices by 
providing an interface between any devices operating 
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at independent or independently controllable clock 
speeds. 

Embodiments of the invention will now be described 
by way of example with reference to the accompanying 
drawings, in which: 

FIG. 1a presents a top-level block diagram of the 
present invention; 

FIG. 1b presents a top-level block diagram of the 
present invention implemented on a computer; 
FIG. 2 presents a flow chart of the operations per- 
formed by the host bus slave interface of the 
present invention; 

FIG. 3 presents a flow chart of the operations per- 
formed by the target bus master interface of the 
present invention; 

FIG. 4 presents a flow chart of the operations per- 
formed by the target bus slave interface; 
FIG. 5 presents a flow chart of the operations per- 
formed by the host bus master interface; and 
FIG. 6 presents a flow chart of the operations per- 
formed by the target bus arbiter. 

FIG. la presents a top-level block diagram of the 
asynchronous PCI-to-PCI bridge (APB) (100). The 
bridge is coupled between a host PCI -compliant device 
(1 02) and a target PCI -compliant device (104) by a host 
PCI bus (106) and a target PCI bus (108) respectively. 
The APB (100) comprises a host bus slave interface 
(110) coupled to a target master bus interface (112), and 
a host bus master interface (114) coupled to a target bus 
slave interface (116). A target bus arbiter (118) is cou- 
pled to the target bus. The function and operation of 
each of these components is further discussed below. 

It is noted that the present invention need not be 
limited in application or scope to PCI-compliant devices. 
Instead, the method and apparatus described herein 
can serve as an asynchronous bridge between any de- 
vices complying with a predefined interface protocol. 
Further, many possible implementations of bridge illus- 
trated in FIG. la are possible. One possible implemen- 
tation would utilize commonly available flip flops and 
other logical memory devices to create a special pur- 
pose APB (10). Similarly, the functions described herein 
performed by the APB (100) could be performed by a 
microprocessor coupled to a memory device. Finally, 
the elements shown in FIG. la could be implemented by 
a computer (120) coupled between the host PCI bus 
(106) and the target PCI bus (108), as shown in FIG. 1b. 
The computer may include, inter alia, a processor (1 22), 
a memory (124), as well as a fixed and/or" removable 
storage device (126) and associated media (128). 
Those skilled in the art will recognize that any combina- 
tion of the above components, or any number of different 
components, peripherals, and other devices may be 
used to implement the processes and structures defined 
herein. 

FIG. 2 presents a flow chart of the operations per- 



formed by the host bus slave interface (110). The proc- 
ess begins and ultimately ends with the host PCI bus 
(106) in an idle state (200). From the idle state (200), 
the host bus slave interface (110) determines whether 

s the host bus has requested access (202) to the bridge. 
This is indicated when the FRAME signal pin on the host 
PCI bus (106) is asserted active. This is indicated when 
the FRAME pin is logically low. Next, the instruction from 
the host PCI bus (106) is examined to determine if the 

10 instruction is an instruction supported (204) by the target 
PCI device (104) and the APB (100). For example, in- 
validate instructions only apply to the system memory 
of the host motherboard, and are not supported by the 
APB or the target PCI device. If this instruction was in- 

is dicated, the APB returns to the idle state (200). There- 
after, the host slave bus interface (110) determines 
(206) if the APB was selected, using the message from 
the host PCI-compliant device (102). Ordinarily, this is 
determined from the address or address range or win- 

20 dowas specified by the message. If the address is within 
the APB (100) address window, the address, data, and 
command are captured (208). This involves storing 
these values to save them for later use. This data will 
later be overwritten in subsequent trials, as described 

25 below. 

Next, the host slave bus interface (110) determines 
whether this was the first trial for the captured command 
(208). If this is not the first trial for this command or in- 
struction, the instruction address, command, and data 

30 is stored for later use. This stored data is later used to 
implement a delayed action interface between the two 
PCI devices. After storing (212) the instruction, the host 
slave bus interface (110) sets (214) a HOST_BUSY flag 
and a 1 ST_TRIAL flag. The HOST_BUSY flag indicates 

35 that the host PCI-compliant device (102) is accessing 
the APB (100). This flag is later used to notify other el- 
ements of the APB that the host is busy. The 1 STJRI AL 
flag is used to implement the function indicated in block 
(210). 

40 Next, after receiving the command instruction from 
the host PCI bus (106), the target bus master interface 
(112) is accessed (216), and further processing (218) is 
performed. Since clock frequency and hence the speed 
of the target PCI bus (108) may be lower than the host 

45 PCI bus (1 06), it is undesirable to hold the host PCI bus 
(106). To avoid holding the host PCI bus (106), retry 
handshakes are asserted (220) to the host PCI bus 
(1 06). This frees the host PCI bus (106) for other oper- 
ations while data is retrieved from or written to the target 

so PCI bus (108). Retry handshake assertion (220) is per- 
formed in compliance with PCI interface protocols which 
are well known in the art, and described in the PCI Local 
Bus Specification, Rev. 2.0, incorporated by reference 
herein. In one embodiment of the present invention, a 

55 delay is inserted before retry handshakes are asserted 
(220) to the host PCI Bus (1 06). This delay allows other 
components to access the PCI Bus (106). This time de- 
lay can be set to any desired value, but should be at 
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least two clock periods. 

While the retry handshakes are being asserted 
(220) to the host PCI (106), the target bus master inter- 
face (112) is activated (216) by generating a HOSTREQ 
signal, and passing that signal to the target bus master 5 
interface (112). 

FIG. 3 is a flow chart that describes the functions 
performed by the bus master interface (112). From the 
idle state (200), the target bus master interface (112) 
checks to see if access to the target bus has been re- 10 
quested (302), by examining the HOSTREQ signal. If 
target bus access has not been requested, the target 
bus master interface (112) returns to the idle state (200). 
If target bus access has been requested, the target bus 
is queried to determine if it is busy (304). This is accom- *5 
plished by examining a QBUSY signal generated by the 
target bus arbiter (118), as described in detail later in 
this specification. If the target bus is busy, it is retried 
until the bus is no longer busy. When the target bus is 
not busy, access handshakes are asserted (306) to the 20 
target bus. This procedure is well known in the art, and 
described in detail in the PCI Local Bus Specification, 
Rev. 2.0, incorporated by reference herein. 

Thereafter, the instruction or command information 
that was stored (212) in the APB (100) is outputted to 25 
the target bus master interface (112). This data is later 
asserted to the target PCI bus (108). Next, the target 
bus master interface (112) checks to determine if the 
access process is completed (308) indicating that the 
target PCI device (104) is ready to accept the instruction 30 
or command. If the target PCI device (104) is not pre- 
pared to accept the instruction or command (310), the 
access process begins anew. If the target PCI device 
(1 04) and the target PCI bus (1 08) is prepared to accept 
the command, processing continues. If an abort com- 35 
mand was received (312) from the target PCI-compliant 
device (104), that target access was completed is re- 
ported (314) to the host slave bus interface (110), and 
abort handshakes are asserted to the target bus. This 
process is well known in the art, and described in detail 40 
in the PCI Local Bus Specification, Rev. 2.0, incorporat- 
ed by reference herein. 

If no abort command was received from the target 
PCI-compliant device (104), the stored instruction or 
command is asserted to the target PCI bus (1 08). If the 45 
instruction was a write command, the data is written 
(318) to the target PCI bus (108), and if the instruction 
was a read command, the data is read (318) from the 
target PCI bus (108). Thereafter, that target access was 
completed is reported (320) to the host slave bus inter- so 
face (110), and normal completion handshakes are as- 
serted (322) to the target bus. 

Referring back to FIG. 2, the reader will recall that 
while the target bus master interface (1 1 2) was activated 
(216), retry handshakes were asserted (220) to the host 55 
PCI bus (106) to command the host bus to re-transmit 
the given instruction. Since the host PCI bus (106) is 
faster than the target PCI bus, this prevents the host PCI 



bus from being hung-up waiting for the target PCI bus 
to respond. In one embodiment, a time delay may be 
implemented before the retry handshakes are asserted 
to allow other devices to access the host PCI bus (1 06). 
After the host PCI bus (106) responds to the retry com- 
mand with a re-transmitted command, the host slave 
bus interface (110) responds as described earlier by 
capturing (208) the re-transmitted command if the in- 
struction is supported (204), and the APB is selected 
(206). Next, the HOST_BUSY flag is examined (210) to 
determine if this is the first pass through the APB (100) 
for this instruction. 

Assuming the process previously described have 
taken place, the HOST_BUSY flag will be set, and the 
host slave bus interface (110) will then compare (222) 
the stored information from the first pass with the cap- 
tured current instruction. If the stored information from 
the first pass and the captured current instruction do not 
match (224), retry handshakes are again asserted (220) 
to the host PCI bus (106), as described earlier. If the 
stored information and the captured current instructions 
match (224) and target bus access is completed (226), 
the host slave bus interface checks to see if an abort 
command was received (228) from the target PCI-com- 
pliant device (104). 

If so, the HOST_BUSY and 1STJRIAL flags are 
cleared (230), and abort handshakes are asserted (232) 
to the host PCI bus (106). If no abort command was re- 
ceived from the target PCI-compliant device (104), 
processing continues as shown in blocks (234-236). If 
the command instruction was to read data from the tar- 
get PCI-compliant device (104), this data is returned 
(234) from the target bus master interface (112) to the 
host PCI bus (106). Finally, processing is completed by 
clearing (236) the HOST_BUSY flag and the 1 stJTRIAL 
flag and asserting normal completion handshakes (238) 
to the host PCI bus (106). This completes the process 
wherein the host PCI-compliant device (102) performs 
as the master, and the target PCI-compliant device 
(1 04) performs as the slave. 

Figures 4 and 5 are flow charts illustrating the op- 
eration of one embodiment of the present invention 
whereby the slower clocked PCI-compliant device op- 
erates as the master and the faster clocked PCI-com- 
pliant device operates as the slave. 

FIG. 4 illustrates the operations performed by the 
target bus slave interface (116). As before, the process 
begins from the idle state (200). First, the target bus 
slave interface (116) determines (402) if the target bus 
requests access to the host PCI bus (106) by examining 
the QREQ flag. Next, the address, data, and command 
of the instruction from the target PCI bus are captured 
(404). This involves storing these values for later use. 
Next, the Q_BUSY flag is set, and the host bus master 
interface is activated. The processes associated with 
the host bus master interface (114) are described below. 

FIG. 5 is a flow chart describing the operations per- 
formed by the host bus master interface (114). From the 
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idle state (200), the host bus master interface (114) de- 
termines if access to the host bus was requested (502) 
by examining the QREGflag. If access was not request- 
ed, the host bus master interface (114) returns to the 
idle state (200). If access was requested, the host bus 
master interface (114) requests access to the host bus 
by activating a H_REQ signal. While the host PCI bus 
may grant the bus (as indicated by the GNT signal), the 
host PCI bus may not be idle. Instead, the GNT signal 
merely indicates that the requestor will be the next own- 
er of the bus. By assuring that the host PCI bus (106) is 
granted and idle before continuing, the host PCI bus is 
not unduly slowed down waiting for a target PCI bus 
(108) response. Further, by obtaining the bus grant, the 
host bus master interface (114) reserves the bus for use 
as soon as it becomes idle. 

The host bus master interface (114) waits until the 
host PCI bus is both granted and idle. When this occurs, 
access handshakes with the host bus are begun and the 
information captured from the target bus (404) is output 
to the host bus master interface (114.) In one embodi- 
ment of the invention, to further assure proper commu- 
nications, access handshakes are delayed until another 
GNT signal is received from the host PCI bus (106). 
These access handshake protocol are well known in the 
art and are described in the PCI Local Bus Specification , 
Rev. 2.0, incorporated by reference herein. Next, the 
host bus master interface (114) determines if access to 
the host PCI bus (106) is completed (510). After access 
is completed, the host master bus interface (114) deter- 
mines if a retry command was received from the host 
PCI bus (106). If a retry command was received (512), 
retry handshakes are asserted to the host bus (51 4), us- 
ing the protocol defined in the PCI Local Bus Specifica- 
tion referenced herein. If a retry command was not re- 
ceived, the host bus master interface checks to deter- 
mine if a host abort command was received (516). If a 
host abort command was received, a H_DONE flag is 
set to report (518) a message to the target bus slave 
interface (116) that host PCI bus access was success- 
fully completed. Thereafter, abort handshakes are as- 
serted (520) to the host PCI bus (106). If an abort com- 
mand was not received, the host bus master interface 
(114) performs the command or instruction supplied 
from the target bus slave interface (1 1 6). If the command 
was a read command, the data from the host PCI bus 
(106) is read (522). If the command was a write com- 
mand, the indicated data is written (522) to the host PCI 
bus (106). Thereafter, a H_DONE flag is set to report 
(518) a message to the target bus slave interface 116 
that host PCI bus access was successfully completed, 
and normal completion handshakes are asserted to the 
host PCI bus (106). Of course, if an illegal or unsupport- 
ed instruction was provided, the command will not be 
supplied to the host PCI bus (106). This error may be 
reported to the target PCI bus (108), or may simply 
cause the APB to hang up. Further, illegal instructions 
may be detected and reported in the target bus slave 



interface (116). 

Returning to FIG. 4, while host bus master interface 
(114) processes are being performed, the target bus 
slave interface (116) checks to see if the host PCI bus 

s access is completed (412), by examining an HJDONE 
signal. If so, the target bus slave interface (116) checks 
(414) to see if the host PCI bus has aborted. If so, the 
Q_BUSY flag is cleared (416), and abort handshakes 
are asserted (41 8) to the target PCI bus (1 08). If no abort 

io message was received, any data read from the host PCI 
bus (106) is returned to the target PCI bus (108). There- 
after, the Q_BUSY flag is cleared (422), and normal 
completion handshakes are asserted (424) to the target 
PCI bus (108). 

15 FIG. 6 presents a flow chart describing the functions 
performed by the target bus arbiter (118). From the idle 
state (200), the target bus arbiter (118) determines if ac- 
cess to the target bus has been requested. This is indi- 
cated by a QREQ signal. When the host PCI bus (106) 

20 is not busy (604) as indicated by the HBUSY signal, the 
target PCI bus (108) is granted (606) to the bus reques- 
tor by setting the QGRANT signal. Thereafter, the 
QBUSY signal is set, indicating that the target PCI bus 
(1 08) is busy. The target bus arbiter (1 1 8) then waits until 

25 the target PCI bus (108) begins access as indicated by 
the QFRAME signal, and then removes the QGRANT 
signal, indicating that the target bus is no longer granted 
to the requestor. Finally, after the target PCI bus access 
is completed (614), the QBUSY flag is cleared (616), 

30 indicating that the target PCI bus is no longer busy, and 
the target bus arbiter returns to the idle state (200), and 
waits for the next request. 

It is noted that while the target PCI-compliant device 
(104) is described above as operating at a clock fre- 

35 quency lower than that of the host PCI-compliant device 
(102), the device clock frequencies need not be so re- 
lated. The present invention provides a bridge between 
any devices with independent or independently control- 
lable clocks. Hence, the present invention may be prac- 

40 ticed with a target PCI compliant device (1 04) with a fast- 
er clock frequency than that of the host PCI-compliant 
device (102), or with a PCI compliant device (104) with 
a variable or controllable clock frequency. 

45 

Claims 

1 . A method of bridging a first device (102, 104) oper- 
ating at a first clock frequency with a second device 
50 (104, 102) operating at a second clock frequency, 
characterized in that it comprises the steps of: 

receiving a first command message from the 
first device (102, 104) in a bridge (100, 120) 
55 coupled between the first device (1 02, 1 04) and 

the second device (104, 102), the message 
comprising a device command; 
storing the first command message in the 
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bridge (100, 120); 

transmitting the first command message from 
the bridge (1 00, 1 20) tothe second device (1 04, 
102); 

receiving a reply message responsive to the 
first command message from the second de- 
vice (104, 102) in the bridge (100, 120); and 
transmitting the reply message to the first de- 
vice (102, 104). 

2. The method of claim 1 characterized in that the first 
device (102, 104) is a PCi-compliant device, the 
second device (104, 102) is a PCI -compliant de- 
vice, and the device command is a PCI-compliant 
device command. 

3. The method of claims 1 or 2 characterized in that 
the first device (1 02) is a host device and the second 
device (104) is a target device. 

4. The method of claims 1 or 2 characterized in that 
the first device (1 04) is a target device and the sec- 
ond device (102) is a host device. 

5. The method of claim 3 or 4 characterized in that: 

the command message comprises a write com- 
mand and data or a read command; and 
the reply message comprises a message indi- 
cating that the data was written to the second 
PCI-compliant device (104; 102) or data from 
the second PCI-compliant device (104, 102) re- 
sponsive to the read command respectively. 

6. The method of claim 3 characterized in that it further 
comprises the steps of: 

(a) commanding the first device (102) to re- 
transmit the first command message; 

(b) receiving the re-transmitted command mes- 
sage from the first device (102) in the bridge 
(100); 

(c) repeating steps (a)-(b) until the stored first 
command message matches the re-transmit- 
ted message; and 

(d) repeating steps (a)-(c) until the reply mes- 
sage is received from the second device (104), 

7. The method of claim 6 characterized in that the 
method further comprises the step of delaying for a 
time period of at least two first clock periods before 
commanding the first PCI-compliant device (102) to 
re-transmit the command message. 

8. The method of claim 6 characterized in that the step 
of receiving the first command message further 
comprises the steps of: 



determining if the PCI-compliant device com- 
mand is supported by the second PCI-compli- 
ant device (104); and 

returning the bridge (1 00) to an idle state when 
5 the PCI-compliant device command is not sup- 

ported by the second PCI-compliant device 
(104). 

9. The method of claim 4 characterized in that it further 
10 comprises a step of accessing the second PCI- 
compliant device (102) comprises the steps of: 

(a) requesting access to the second PCI-com- 
pliant device (102) by transmitting a request 
signal from the bridge (100) tothe second PCI- 
compliant device (102); 

(b) receiving a signal from the second PCI-com- 
pliant device (1 02) in the bridge (1 00) indicating 
that the second PCI-compliant device (1 02) has 
been granted to the bridge; 

(c) receiving a signal indicating that the second 
PCI-compliant device (102) is idle; 

(d) releasing the second PCI-compliant device 
(102) if the first PCI-compliant device (102) is 
not idle; 

(e) repeating steps (a)-(d) until the second PCI- 
compliant device (102) is both granted and idle; 
and 

(f) performing PCI access handshaking and 
transmitting the first command message from 
the bridge (100) to the second device (102) 
when the second PCI-compliant device (1 02) is 
both granted and idle. 

10. The method of claim 9 characterized in that it further 
comprises the step of repeating the step of receiv- 
ing a signal from the second PCI-compliant device 
(102) in the bridge (100) indicating that the second 
PCI-compliant device (1 02) has been grantedtothe 
bridge (1 00) before performing the step of perform- 
ing PCI access handshaking. 

11. An apparatus for bridging a first PCI-compliant de- 
vice (102) operating at a first clock frequency with 
a second PCI-compliant device (104) operating at 
a second clock frequency, characterized in that it 
comprises a bridge (100) coupled between the first 
PCI-compliant device (102, 104) and the second 
PCI compliant device (102, 104), the bridge (100) 
further comprising: 

a first bus slave interface (110) coupled to the 
first PCI-compliant device (102), the first bus 
slave interface (110) comprising means for re- 
ceiving a first command message, for storing 
the first command message, for commanding 
the first PCI-compliant device (1 02) to re-trans- 
mit the command message, for receiving the re- 
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transmitted command message from the first 
PCI-compliant device (102), for determining if 
the stored first command message matches the 
re-transmitted command message, for deter- 
mining if a reply message responsive to the first s 
command message is received, for transmitting 
the reply message to the first PCI -compliant de- 
vice (102); and 

a second bus master interface (1 1 2) coupled to 
the first bus slave interface (110) and the sec- 10 
ond PCI-compliant device (104), the second 
bus master interface (112) further comprising 
means for transmitting the first command mes- 
sage to the second PCI -compliant device (1 04), 
and means for receiving the reply message is 
from the second PCI-compliant device (104) 
and forwarding the reply message to the first 
bus slave interface (110). 

12. The apparatus of claim 11 characterized in that the 20 
bridge (100) further comprises a target bus arbiter 
(118) for arbitrating access to the second PCI-com- 
pliant device (104). 

13. The apparatus of claim 11 characterized in that the 25 
bridge (100) further comprises: 

a second bus slave interface (116) coupled to 
the second PCI-compliant device (104), the 
second bus slave interface (116) comprising 30 
means for receiving a first command message 
from the second PCI-compliant device (104), 
the message comprising a PCI-compliant de- 
vice command, means for storing the first com- 
mand message, means for transmitting a reply 35 
message responsive to the first command mes- 
sage to the second PCI-compliant device (104); 
and 

a first bus master interface (11 4) coupled to the 
second bus slave interface (116) and the first 40 
PCI-compliant device (1 02), comprising means 
for accessing to the first PCI-compliant device 
(102), means for transmitting the first command 
message to the first PCI-compliant device (1 02) 
when the first PCI-compliant device (102) is 45 
available and means for receiving the reply 
message from the first PCI-compliant device 
(102). 
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